Two large dead-code blocks left over from the original WIP:

- posting/index.go: ~175 lines of an alternate
  InsertTokenizerIndexes implementation, fully commented out. The
  live implementation directly above it supersedes it; keeping the
  commented variant just made the file harder to follow. Also drop
  the scattered "//fmt.Println(...)" leftovers next to live code.

- worker/draft_test.go: BenchmarkProcessListIndex was added entirely
  commented out and references methods (DefaultPipeline,
  ProcessListWithoutIndex, ProcessListIndex) that don't exist on
  MutationPipeline. If we want a benchmark for the pipeline, we
  should write one against the real API.

No behavior change.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Replace the hardcoded \`featureFlag := true\` in applyMutations with
a real superflag knob, defaulted off:

- Add WorkerOptions.MutationsUsePipeline (bool) in x/config.go.
- Extend the feature-flags superflag with mutations-use-pipeline=false
  and wire alpha to populate WorkerConfig.MutationsUsePipeline from it.
- worker/draft.go applyMutations now branches on
  x.WorkerConfig.MutationsUsePipeline; default false routes mutations
  through the legacy path, preserving current behavior.

Tests can opt into the new pipeline by setting
x.WorkerConfig.MutationsUsePipeline = true. CLI usage:
  dgraph alpha --feature-flags="mutations-use-pipeline=true"

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

TestCount is t.Skip()'d on the branch, but the reason wasn't
recorded. Investigation: the test launches concurrent transactions
sharing entity uids and bypasses the Oracle's conflict-checking
commit path — it just calls CommitToDisk() directly with disjoint
commit timestamps. Both the legacy AddMutationWithIndex path and
the new mutation pipeline fail it identically: with two threads
adding edges to the same subject's [uid] @count predicate, neither
path can serialize @count updates without real txn conflicts, so
the count index ends up inconsistent and many subjects are missing
from count(N).

This is expected without conflict checking — the unit harness can't
exercise the safety the Oracle provides. Re-enable when we wire
either: (a) Oracle.WaitForTs/IsAborted into the harness, or (b)
this test through worker.applyMutations() (which does invoke the
Oracle conflict path).

Single-thread TestCount passes, so the per-predicate pipeline's
own count logic is correct in the absence of contention. The
existing TestStringIndexWithLang covers the multithreaded happy
path with disjoint uids.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

…ssCount

Bug: scalar @count writes were nondeterministically losing data under
concurrent transactions. Roughly half the deltas committed by the
new mutation pipeline contained only a [DeleteAll] posting and no
Set, so reads at maxTs returned an empty value list.

Root cause: in ProcessSingle, handleOldDeleteForSingle appends a
synthetic Del-of-old-value to postings[uid] alongside the user's
Set, so InsertTokenizerIndexes / ProcessReverse / count diffing can
see the prior value. ProcessCount then iterates the postings and
calls list.updateMutationLayer(post, singleUidUpdate=true, ...) on
each. For non-Lang scalar predicates fingerprintEdge returns
math.MaxUint64, so the synthetic Del and the user Set both have
Uid == math.MaxUint64. The first iteration (Set new) leaves
mutationMap.currentEntries = [DeleteAll, Set new]; the second
iteration (Del old) finds the Set we just inserted via findPosting
and applies updateMutationLayer in singleUidUpdate mode, which
unconditionally rewrites currentEntries to [DeleteAll] (the Del
branch never appends mpost) — wiping the new value.

Fix: in ProcessCount, when iterating a !isListEdge predicate's
postings, if the list contains a Set/Ovr posting, treat any Del as
synthetic and skip it for the data-list update. Standalone user Dels
(no accompanying Set) are still applied. Index/reverse/count diffing
already happen before ProcessCount runs and aren't affected.

Repro: TestPipelineCountIndexConcurrent in worker/sort_test.go is a
new conflict-aware in-process harness that mirrors the systest
TestCountIndexConcurrentSetDelScalarPredicate. It runs 200
contending transactions setting <0x1> <name> "name<rand>" against a
"string @index(exact) @count" schema with a fakeOracle that
implements the same hasConflict algorithm as
dgraph/cmd/zero/oracle.go. Pre-fix the test fails roughly 50% of
runs with an empty data list and the wrong count buckets; post-fix
it is stable across 20+ -count iterations and under -race.

Existing tests (TestScalarPredicateIntCount, *RevCount, *Count,
TestSingleUidReplacement, TestDeleteSetWithVarEdgeCorruptsData,
TestStringIndexWithLang, TestMultipleTxnListCount, TestGetScalarList,
TestDatetime) all pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

When loading via dgraph live (or any mutation source whose uids span
the full uint64 range, including xidmap-assigned uids), the
per-predicate pipeline hung indefinitely on the very first batch with
zero forward progress. A goroutine dump showed the dispatcher
goroutine wedged on \`chan send (nil chan)\` at the line:

    chMap[int(uid)%numGo] <- uid

uid is uint64. Casting directly to int produces a negative value for
uid >= 2^63, so int(uid)%10 can be in [-9, -1]. chMap[-3] returns the
zero value for a chan uint64, which is a nil channel; sending on a
nil channel blocks forever.

The 10 worker goroutines (also created here) were idle on
\`for uid := range uids\` since no uids ever reached them, so the
parent \`wg.Wait()\` and the surrounding errgroup never returned.
applyMutations therefore never released the txn, the alpha's old-txn
abort loop kept retrying every minute, and live-load showed
"Txns: 0  N-Quads: 0" indefinitely.

Fix: hash unsigned, then cast: \`chMap[int(uid%uint64(numGo))]\`.

Verified end-to-end with the live loader against the 1million.rdf.gz
benchmark dataset (1,041,684 n-quads, schema mixes [uid] @reverse
@count, [uid] @count, datetime @index(year), string @index(...) @lang,
geo @index(geo), string @index(exact) @upsert):

  legacy   :  13.85s / 14.74s  (avg ~14.3s,  ~77k n-quads/s)
  pipeline :   9.65s /  9.36s  (avg ~9.5s,  ~116k n-quads/s)

That is ~1.50x faster on a realistic multi-predicate, multi-index
workload — i.e. the case the per-predicate runner pipeline is built
for.

Also adds worker/pipeline_bench_test.go: in-process Go benchmarks
comparing legacy runMutation vs newRunMutations across a matrix of
(predicates, edges-per-predicate, indexed/non-indexed) shapes. They
show the pipeline loses ~2x on tiny mutations (1-10 edges) and wins
1.2x-1.55x on bulk (10 preds x 100+ edges, indexed or not), which is
why the feature flag stays default-off and the live-loader speedup
above is the right place to evaluate this work.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

The benchmark matrix in worker/pipeline_bench_test.go showed the
pipeline loses ~2x on small mutations (≤10 edges total) and wins
~1.5x on bulk (live-loader sized: 1000 edges per txn across many
predicates). A binary on/off flag forces an all-or-nothing choice,
penalising whichever side of that crossover the workload spends most
time on.

Replace MutationsUsePipeline (bool) with MutationsPipelineThreshold
(int):

  threshold = 0   -> never use the pipeline (default; legacy behavior)
  threshold = 1   -> always use the pipeline (any txn with ≥1 edge)
  threshold = N   -> use the pipeline only when len(m.Edges) >= N

The threshold compares against total edges in the proposal. From the
benches the crossover is around 100; the live-loader 1M dataset uses
~1000 edges per txn, so anything from 100-1000 will engage the
pipeline only on bulk-shaped mutations and leave small interactive
mutations on the legacy serial path.

Wiring:
  - x.WorkerConfig.MutationsPipelineThreshold (int) replaces the
    bool field.
  - feature-flags superflag: "mutations-pipeline-threshold=0".
  - alpha/run.go reads it via featureFlagsConf.GetInt64.
  - worker/draft.go applyMutations branches on
    `t > 0 && len(m.Edges) >= t`.

Verified end-to-end against the live-loader benchmark
(1million.rdf.gz, official 1M schema):
  threshold=0   : 13.56s, 80,129 N-Quads/s    (legacy, matches baseline)
  threshold=1   :  9.92s, 115,742 N-Quads/s   (always-on, matches prior)

CLI usage:
  dgraph alpha --feature-flags="mutations-pipeline-threshold=200"

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Engages the per-predicate mutation pipeline by default so that systest
runs (and any other test suites that don't override feature-flags)
exercise the pipeline path on every mutation, not the legacy serial
path. Threshold of 1 means "any mutation with ≥1 edge takes the
pipeline" — i.e. always on.

This is a deliberate ramp toward shipping the pipeline. Operators who
want to opt small interactive mutations out of the pipeline (where
benches showed ~2x slowdown for ≤10-edge txns) can set a higher
threshold:

  dgraph alpha --feature-flags="mutations-pipeline-threshold=200"

To turn the pipeline fully off, set 0.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

The original branch commit 41d6445 ("fixed some bug") replaced
the IsEmpty(readTs) call in IterateDisk with a hardcoded `false`,
forcing every key found by the iterator to be reported as non-empty.
That broke has(<predicate>) for any uid whose value had been removed
via star-deletion (<uid> <pred> *): the data list still exists in
badger with a DeleteAll marker on top, but the live posting list is
empty at readTs — IsEmpty returns true and the uid should be skipped.

Surfaced by systest TestSystestSuite/TestHasDeletedEdge in
systest/mutations-and-queries: 3 nodes are created with <end> "",
one is star-deleted, follow-up has(end) is expected to return 2 uids.
With IsEmpty stubbed to false it returned 3.

No comment was left on the original change. Restoring the call. The
mutations-and-queries package is fully green with this in place
(66/66 tests pass including TestHasDeletedEdge); if a real underlying
issue motivated the original disable we'll chase it with a real
diagnosis instead of silently dropping a safety check.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>